\chapter{Besluit}
\label{Besluit}

Het eerste deel van onze thesis bestond uit het testen van Narcissus. Hiervoor hebben we een bestaande testsuite\cite{ecmatest} zo aangeast dat 
zijn tests in Narcissus uitgevoerd konden worden. Verder hebben we tijdens het eerste deel van onze thesis verschillende problemen die er nog waren bij Narcissus
opgelost. Dit heeft ons ook geholpen om een beter inzicht te krijgen in Narcissus.

Tijdens het tweede deel van de thesis hebben we het prototype ge\"implementeerd, we hebben verschillende manieren om functies af te schermen binnenin Narcissus
uitgeprobeerd om tot bij onze uiteindelijke oplossing terecht te komen. We hebben nagedacht over verschillende mogelijke aanvallen
tegen ons systeem, hiervoor hebben we ons laten inspireren door verschillende gerelateerde research papers en artikels  
\cite{XSScheatsheet} \cite{cajalimit} \cite{conscript} \cite{caja} \cite{webjail}. Buiten de code van Narcissus is er geen externe code gebruikt.

De testsuite werd opnieuw uitgevoerd nadat alle aanpassingen aan Narcissus gemaakt waren. Uit de testresultaten blijkt dat er geen extra tests falen door de door ons doorgevoerde aanpassingen in Narcissus. De testsuite test wel enkel voor standaard JavaScript 
functionaliteiten en niet de functionaliteiten die door de policies afgeschermd kunnen worden.
De effecten van verschillende policies worden dus niet getest, maar de aanpassingen hebben in ieder geval geen nieuwe fouten in Narcissus veroorzaakt.

Dat de gewenste operaties degelijk afgeschermd worden, is getest door een aantal sunny days scenario's te testen voor elke operatie.

\pagebreak

\section{Verwezenlijkingen}

We hebben mits sommige beperkingen in grote lijnen onze doelstellingen kunnen bereiken. Het prototype kan gebruikt worden om
policies toe te passen zonder dat er client-side aanpassingen nodig zijn. Verder moet de code die ge\"evalueerd wordt niet aangepast worden.
Zo combineert het prototype het voordeel van Webjail \cite{webjail}, waar policies kunnen toegepast worden op code zonder dat deze code herschreven moet worden, met het voordeel van Caja \cite{caja}, waar policies kunnen toegepast worden zonder dat er client-side aanpassingen nodig zijn.

Het afschermen van functies in Narcissus was redelijk eenvoudig omdat Narcissus een relatief kleine codebase heeft en geschreven is in JavaScript.
Dit was ook \'e\'en van de redenen waarom we Narcissus gebruikt hebben. We hadden echter wel problemen met de SpiderMonkey context volledig te scheiden van
de Narcissus context. Er bleken nog veel mogelijkheden te bestaan om uit de sandbox van Narcissus te breken. 
Deze problemen hadden soms niet zo voor de hand liggende oplossingen. We konden ons voor deze problemen dan ook vaak niet baseren op andere methodes omdat onze aanpak (d.m.v. een JS engine in een JS engine) uniek is.

\pagebreak

\section{Beperkingen}
Deze sectie geeft een overzicht van de beperkingen die ons systeem nog heeft, een deel van deze beperkingen zijn reeds aan bod gekomen in de vorige stukken.

\subsubsection{Narcissus.interpreter.evaluateUrl()}

Deze methode wordt gebruikt om externe JavaScript bestanden in te laden. Zoals in hoofdstuk \ref{Narcissus} te zien was, maakt
deze methode gebruik van het XMLHttpRequest object. Omdat het XHR object beperkt wordt door de same-origin policy is het dus niet mogelijk om bestanden die van andere origines afkomstig zijn uit te voeren. Er is geen manier om deze beperking te omzeilen via JavaScript zonder gebruik te maken van een browser addon. Een andere mogelijke oplossing voor dit probleem zou kunnen zijn dat de bestanden op de server kunnen gedownload worden door een server-side script, opgeroepen via XHR in Narcissus. 

\begin{lstlisting}[caption=XHR met server-side script.]
 function evaluateUrl(u, p, f, l){
    //maakt gebruikt van het server-side script op de lokale server
     eval_req.open('GET', 'http://my.origin.com?get_file.php?url=' + u , false); 
     eval_req.send(null);
     if (eval_req.status !== 200)
        throw new Error("Error loading " + u);
     return evaluate(eval_req.responseText,p,f,l);
  }
\end{lstlisting}

\subsubsection{IFrame}

Zoals eerder vermeld wordt de iframe niet ondersteund. Er zijn twee mogelijke manieren om een iframe te gebruiken. Een iframe kan
inline html meegeven of er kan een pagina in een iframe geladen worden door gebruik te maken van het iframe.src attribuut.

Als er gebruik wordt gemaakt van het iframe.src attribuut zijn er opnieuw problemen door de same-origin policy.
Een iframe dat een source heeft in een andere origin kan niet aangepast worden in JavaScript. Deze iframe kan dan terug code uitvoeren in SpideMonkey zonder dat de policy er nog invloed op heeft.

Als html inline meegegeven wordt, zit de iframe wel in dezelfde origin, hierdoor lijkt het wel mogelijk om deze methode te ondersteunen. Het prototype ondersteunt deze methode echter nog niet omdat er hier nog andere problemen mee zijn. Het prototype kan inline iframes nog niet correct parsen, de reden hiervoor is nog niet voldoende onderzocht.

\subsubsection{document.write()}

Deze functie kan enkel nog gebruikt worden om xhtml strict te schrijven naar het document (plaintext, zonder html tags, wordt ook aanzien als xhtml strict).
De functieoproepen worden wel gebufferd tot dat er een xhtml strict stuk tekst in de buffer zit. Zo kan een stuk tekst bestaande uit meerdere write 
operaties toch nog geschreven worden.

\medskip
\begin{lstlisting}[caption=Gebufferde document.write()., label=code:buffer]
 //schrijft <p>Hello, world!</p> naar het document
 document.write('<p>');
 document.write('Hello, world!');
 document.write('</p>');
\end{lstlisting}

De reden dat het prototype enkel xhtml strict aanvaard voor de document.write() methode is dat onze implementatie onvolledige tags atlijd
zal afsluiten. Als er niet zou gebufferd worden tot er xhtml sticte tekst geschreven kan worden zou het voorbeeld in listing \ref{code:buffer}
resulteren in twee lege paragrafen met een stuk tekst ertussen.

Een extentie op deze oplossing zou kunnen zijn dat de niet geschreven document.write() oproepen die zich nog in de buffer bevinden, op een bepaald moment toch nog te schrijven. Bijvoorbeeld wanner het document.onload event afgevuurd wordt. 
Dit event wordt enkel afgevuurd als het document volledig klaar is en dus zouden alle mogelijke document.write() oproepen al opgeroepen moeten zijn. 
Deze oplossing is niet perfect omdat de locatie waar er document.write() opgeroepen wordt, effect heeft op de resultaat ervan.

\subsubsection{Flash}

Flash wordt in het prototype ook nog niet ondersteund.
Het is ook mogelijk om vanuit Flash JavaScript uit te voeren. De JavaScript code die door flash uitgevoerd wordt draait in de context
van SpiderMonkey, zo zouden de policies dus omzeild worden. We hebben geen betere oplossing voor dit probleem gevonden dan flash volledig te blokkeren. 

\pagebreak

\subsubsection{Reguliere Expresies}

Om er voor te zorgen dat events niet uitgevoerd worden wanneer HTML toegevoegd wordt aan de DOM. Vormen we de HTML in eerste instantie om 
met reguliere expressies. Hoewel de reguliere expressie moeilijk te omzeilen lijkt, is dit waarschijnlijk niet de beste manier.
De browser is een complexe omgeving, die ook van slecht gevormde HTML, nog de best mogelijke structuur probeert te maken.


\subsubsection{Veiligheid}

We hebben veel manieren om uit Narcissus te kunnen breken beveiligd, maar we kunnen niet met zekerheid beweren dat er niet meer uit Narcissus gebroken kan worden. Dit punt is het meest nadelige aan ons prototype, de veiligheid ervan kan moeilijk tot 
niet aangetoond worden. Dit komt omdat de browser een heel complexe omgeving is waarin tal van verschillende API's gebruikt worden. We hebben wel de meest gebruikelijke aanvallen uit de literatuur bekeken en proberen toe te passen op het protoype. En daarbuiten hebben we ook gekeken naar bekende XSS aanvallen. 
Waardoor we kunnen zeggen dat we zelf geen mogelijke aanvallen kunnen bedenken, en niet dat er geen meer zijn.

\pagebreak

\section{Conclusie}

Met ons prototype hebben we aangetoond dat het mogelijk is om met Narcissus een veiligheidsarchitectuur te ontwikkelen waarmee policies kunnen afgedwongen worden op JavaScript code.
En dit zonder dat aan de kant van de client iets extra moet ge\"installeerd worden of dat er aanpassingen gedaan moeten worden aan de code. 
Mits enige kennis van JavaScript en de nodige uitleg moet men nu ook in staat zijn zelf nieuwe policies te schrijven. 
De policies die wij beschreven hebben zijn nog op hoog niveau. Het toevoegen van complexere policies zou ook geen enkel probleem mogen zijn. 
Dit prototype is oorspronkelijk bedoeld om in een iframe ingeladen te worden en daarin op 1 component een door de integrator bepaalde policy af te dwingen. 
Het lijkt ons ook mogelijk om Narcissus te gebruiken voor verschillende componenten. 
Het afdwingen van de policy op de juiste component is hierbij geen grote moeilijkheid meer.
Er zouden bijvoorbeeld meerdere instanties van Narcissus aangemaakt kunnen worden, waarbij elke instantie 
zijn eigen omgeving en policy heeft. Bemerk wel dat onder andere de DOM gedeeld is dan, en dat ook daar oplossingen voor geboden moeten worden. 
Dit was buiten de scope van de thesis maar zou zeker nog een meerwaarde kunnen bieden aan dit prototype.

Verder mogen we ook best tevreden zijn met de patches die we gedaan hebben voor Narcissus. 
Als ook de testresultaten die we ervoor hebben verzameld. Dit kan toekomstig werk met Narcissus hopelijk vergemakkelijken. 

